Systems and methods for optimizations involving insufficient funds (nsf) conditions

ABSTRACT

Systems and methods for optimizations involving insufficient funds conditions are provided. An identification of a first account of a customer of a financial institution may be received by a financial system comprising one or more computers. The first account may be a deposit account at the financial institution. Interest income and non-interest income attributable to one or more of a plurality of accounts, including the first account, that the customer has with the financial institution may be analyzed by the financial system. Based at least in part on the analyzed interest income and non-interest income, a recommended next action associated with the first account may be determined by the financial system. The recommended next action may be associated with an actual or potential insufficient funds (NSF) condition associated with the first account.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 14/100,242, filed Dec. 9, 2013, which is a continuation of U.S.application Ser. No. 13/226,926, filed Sep. 7, 2011, now U.S. Pat. No.8,635,134 issued Jan. 21, 2014, the contents of which are incorporatedby reference herein in their entireties.

FIELD OF THE INVENTION

Aspects of the invention relate generally to insufficient funds or notsufficient funds (NSF) conditions, and more particularly, to systems andmethods for optimizations involving NSF conditions.

BACKGROUND OF THE INVENTION

Many financial institutions wish to provide a more tailored handling ofNSF conditions for customers. Indeed, while NSF conditions can generatefee or income opportunities for financial institutions, the way in whichthe NSF conditions are handled can impact customer experiences,satisfaction, loyalty, and/or retention. Thus, there is an opportunityfor systems and methods for optimizations involving NSF conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale, and wherein:

FIG. 1 illustrates a block diagram of an example system that supportsoptimizations involving NSF conditions, according to an illustrativeembodiment of the invention.

FIG. 2 illustrates a flow diagram of an example method for reactivelyrecommending and/or implementing an action associated with an NSFcondition, according to an illustrative embodiment of the invention.

FIG. 3 illustrates a visual diagram of example customer segments thatmay be utilized in association with various embodiments of theinvention.

FIG. 4 illustrates a flow diagram of an example method for proactivelyrecommending and/or implementing an action associated with an NSFcondition, according to an illustrative embodiment of the invention.

FIG. 5 illustrates a flow diagram of an example method for calculatingan overdraft limit, according to an illustrative embodiment of theinvention.

DETAILED DESCRIPTION

The invention will now be described more fully hereinafter withreference to the accompanying drawings, in which example embodiments ofthe invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theexample embodiments set forth herein; rather, these example embodimentsare provided so that this disclosure will be thorough and complete, andwill fully convey the scope of the invention to those of ordinary skillin the art. Like numbers refer to like elements throughout.

Embodiments of the invention may provide systems and methods foroptimizations involving NSF conditions. These optimizations may take awide variety of different factors into account, including but notlimited to, interest income associated with a customer, non-interest(e.g., fee, etc.) income associated with the customer, customersegmentation, attrition risk, and/or a customer tolerance for paying NSFfees. In certain embodiments, an optimization may take a relativelyholistic view of a customer's relationship with a financial institution(e.g., a bank, etc.). Additionally, as desired, optimizations may beperformed in a reactive and/or in a proactive or anticipatory manner.For example, a relatively optimal best next action (BNA) may bereactively determined based upon the identification of an NSF situation.As another example, an overdraft limit amount may be proactivelydetermined for a customer based at least in part upon an optimization.

It will be appreciated that the optimizations described herein, or atleast a portion thereof, can be performed by a service provider, afinancial institution, or a combination thereof on a periodic basis,based upon the identification of an event (e.g., an NSF event, etc.),and/or on an as-requested basis, according to one or more exampleembodiments of the invention. As an example, the service provider mayoperate as an application service provider (ASP) that supportsinteraction with a financial institution computer, and allows a user ofthe financial institution computer to identify or provide data ofcustomers to be analyzed for optimizations, as well as any configurationoptions or preferences for performing the optimizations. The results ofthe optimizations can then be provided for access by a financialinstitution computer communicating with the service provider via one ormore suitable networks. For example, the financial institution can havecustomer management software that receives the results of theoptimizations performed by the service provider. In certain embodiments,a service provider may provide optimization functionality to a pluralityof financial institutions, according to an example embodiment of theinvention. In other embodiments, the service provider can be a unit of afinancial institution that provides the optimization functionality toone or more units of the same financial institution, a subsidiary of thesame financial institutions, or other financial institution(s) vianetworked financial institution computers. For example, theoptimizations described herein may also be performed by optimizationsoftware running locally at a financial institution computer. In thisregard, the financial institution computer can access, either locally orvia a network, data for customers to be analyzed by optimizations, aswell as any configuration options or preferences for performing theoptimizations.

I. System Overview

FIG. 1 illustrates a block diagram of an example system 100 thatsupports optimizations involving NSF conditions, according to anillustrative embodiment of the invention. Although various computingdevices and/or computers are illustrated in FIG. 1, it is appreciatedthat corresponding entities and/or individuals are associated with eachof the computers illustrated. According to various embodiments, theremay be: one or more financial service provider systems 105, eachassociated with one or more optimization computers 160, and one or morefinancial institution systems 106, each associated with one or morefinancial institution computers 140. In certain embodiments, thefinancial service provider systems 105 may be associated with afinancial service provider entity, and the financial institution systems106 may be associated with one or more financial institutions. Accordingto various embodiments, there may be any number of each entity type, andeach entity may be associated with any number of suitable systems,computers, computing devices, and/or other devices. For simplicity, theentities, systems, computers, and/or devices may be referenced in thesingular, but it is appreciated that the same description applies toembodiments including multiple entities, systems, computers, and/ordevices. Similarly, for each of the computers described herein, it isappreciated that the computer may include any number of suitablecomponents and/or functionalities. Moreover, although detaileddescriptions of system components are provided for the financial serviceprovider system 105, it is appreciated that any of the financialinstitution systems 106 may be configured in any suitable manner, whichmay be similar to that described herein for the financial serviceprovider system 105. In this regard, the financial institution computerscan include one or more memory devices, processors, input/output (I/O)interfaces, and network interfaces. The one or more memory devices maystore computer-executable instructions, which may be accessed andexecuted by the one or more processors to provide the functionalitydescribed herein with respect to the financial institution computers.

As shown in FIG. 1, the financial service provider system 105 and thefinancial institution system 106 may be in communication with each othervia one or more suitable networks 145, which, as described below, caninclude one or more separate or shared private and/or public networks,including the Internet, a public switched telephone network, one or morelocal area networks, and/or one or more wide area networks. In addition,the financial service provider system 105, including at least oneoptimization computer 160, can have access to one or more databases 110a-n or other storage of data via one or more suitable networks 144,which may be the same as or different from networks 145. Thesecomponents will now be discussed in further detail.

The financial service provider system 105 may include any number ofoptimization computers 160 that operate to obtain certain informationassociated with accounts of customers of one or more financialinstitutions, and further to perform one or more NSF optimizations basedat least in part upon the account data of the customers. In addition,the one or more optimization computers 160 may communicate with anynumber of financial institution computers 140 to receive business rules,options, preferences, and/or constraints for performing one or moreoptimizations described herein, as well as to provide one or moreresults of the performed optimizations to any number of financialinstitution computers 140. An optimization computer 160 may be anysuitable processor-driven device, such as, but not limited to, a servercomputer, a mainframe computer, one or more networked computers, adesktop computer, a personal computer, a digital assistant, a personaldigital assistant, a digital tablet, an Internet appliance, anapplication-specific circuit, a microcontroller, a minicomputer, or anyother processor-based device. The execution of suitablecomputer-implemented instructions by the optimization computer 160 mayform a special purpose computer or other particular machine that isoperable to facilitate the processing of the optimizations, as well asthe receipt and output of data associated with the optimizations.Although a single optimization computer 160 is described herein, theoperations and/or control of the optimization computer 160 may bedistributed among any number of computers and/or processing components.

In addition to having one or more processors 164, the optimizationcomputer 160 may include one or more memory devices 162, one or moreinput/output (I/O) interfaces 166, and one or more network interfaces168. The memory devices 162 may be any suitable memory devices, forexample, caches, read-only memory devices, random access memory devices,magnetic storage devices, removable storage devices, etc. Additionally,any number of logical data storage constructs may be stored as desiredwithin the memory devices 162, such as an optimization database 170and/or any number of other suitable databases. In addition or in thealternative, while databases 110 a-n may be accessed via a network 144in some embodiments, any of databases 110 a-n may be stored withinmemory devices 162 without departing from example embodiments of theinvention. The memory devices 162 may further store a wide variety ofdata, such as any number of data files 172. Additionally, the memorydevices 162 may store executable instructions and/or various programmodules utilized by the optimization computer 160, for example, anoperating system (OS) 174, a database management system (DBMS) 176, anoptimization processing module 180 and/or one or more host modules 178.

The data files 172 and/or the optimization database 170 may include anysuitable data that facilitates the receipt and/or processing of datautilized in association with the NSF optimization processing. Forexample, the data files 172 and/or optimization database 170 may includedata derived or received from databases 110 a-n, any business rules,options, preferences and/or constraints received from one or morefinancial institution systems 106, and/or default business rules,options, preferences, and/or constraints, as well as processing resultsfrom the performed optimizations (e.g., recommended BNAs, determinationsof overdraft limit amounts, etc.) that are made available to one or morefinancial institution systems 106. The optimization processing module180 may store predictive models, calculation algorithms, processinglogic, and/or various rules utilized to perform one or more NSFoptimizations. In some example embodiments, the optimization processingmodule 180 may store processing logic, business rules, and/or othersoftware that is less prone to change over time, while other logic,rules, predictive models, and/or calculation algorithms that are morelikely to change or be modified may be stored in data files 172 and/oroptimization database 170. Many variations of the optimization database170, data files 172, and/or optimization processing module 180 areavailable in accordance with example embodiments of the invention. It isappreciated that the illustration of an optimization database 170 as aseparate database from the data files 172 and/or any other data storagemeans is provided for illustrative purposes, and that any data may bestored in any arrangement, separate or together with other data storedby the optimization computer 160.

The OS 174 may be a suitable software module that controls the generaloperation of the optimization computer 160. The OS 174 may alsofacilitate the execution of other software modules by the one or moreprocessors 164, for example, the optimization processing module 180and/or the host module(s) 178. The OS 174 may be, but is not limited to,Microsoft Windows®, Apple OSX™, Linux, Unix, or a mainframe operatingsystem. The host modules 178 may include any number of suitable hostmodules that manage interactions and communications between thefinancial service provider system 105 and external systems, such asfinancial institution system 106 (e.g., financial institution computer140). In this regard, the host modules 178 can interface with othermodules such as the optimization processing module 180 in order tofacilitate the procurement, receipt, and/or processing of data fromdatabases 110 a-n, as well as business rules, options, preferences,and/or constraints from the financial institution system 106; and managerequests from one or more financial institutions and/or financialinstitution computer users (e.g., financial institution employees) toperform one or more NSF optimizations and/or requests to receive one ormore results from the performed NSF optimizations.

Additionally, in certain embodiments, the host modules 178 may beconfigured to generate and/or to present a wide variety of differentinterfaces and/or graphical user interfaces, such as one or moreinterfaces that facilitate the receipt of data and/or requests from, ora presentation of results or other information, to the financialinstitution system 106 and/or financial service provider system 105. Aninterface can be in the form of one or more browser-based orInternet-based Web pages, although interfaces can also be presentedthrough specialized software programs (e.g., stand-alone application,applet, mobile device application, etc.), according to an exampleembodiment of the invention. It will be appreciated that the interfacecan be formatted for display on a mobile device (e.g., personalcommunications device like a BlackBerry, iPhone, etc.) or non-mobiledevice (e.g., desktop computer, server computer, etc.), according to anexample embodiment of the invention. The interface may be associatedwith security settings to enable access by certain registered users ofthe financial service provider system 105 and/or financial institutionsystem 106. As desired, a private interface may be branded in accordancewith specifications and/or preferences of a partner entity.Additionally, as desired in certain embodiments, the host modules 178may be configured to provide a web services interface layer to anotherentity or component of the system 100.

The optimization processing module 180 may include one or more suitablesoftware modules that are operable, configured, and/or programmed toidentify recommended optimal actions associated with actual and/orpotential NSF conditions. As desired, the optimization processing module180 may evaluate a wide variety of account data associated with variousaccounts of customers of one or more financial institutions, such asdeposit account data, credit account data, loan account data, and/orother types of account data. The optimization processing module 180 mayadditionally be configured to evaluate both interest and non-interestincome associated with accounts. In certain embodiments, theoptimization processing module 180 may be configured to evaluate accountdata in order to assign customers to various customer segments. Thevarious customer segments may then be utilized during subsequent NSFoptimization operations.

In certain embodiments, the optimization processing module 180 may beconfigured to invoke a wide variety of predictive models that evaluatecustomer account activity. For example, the optimization processingmodule 180 may be configured to invoke one or more predictive modelsthat determine or calculate respective attrition risks associated withvarious customers. In certain embodiments, the optimization processingmodule 180 may be configured to evaluate account data in order todetermine or calculate customer tolerances or NSF capacities. A customertolerance is a sensitivity for incurring further or additional NSF fees.For example, the optimization processing module 180 may evaluate accountand NSF fee data for a customer in order to determine a customertolerance for paying an NSF fee. Indeed, the optimization processingmodule 180 may be configured to implement a wide variety of suitableprocessing methods and/or techniques as desired in various embodimentsof the invention.

Additionally, the optimization processing module 180 may be configuredto receive data from the optimization database 170, the data files 172,and/or from any number of external sources, such as the externaldatabases 110 a-n and/or the financial institution computers 140. Theoptimization processing module 180 may additionally be configured tocommunicate information associated with recommended BNAs to a widevariety of different recipients, such as the financial institutioncomputers 140. As desired, a wide variety of different reportingfunctions may also be performed by the optimization processing module180.

Additional details of the operations of the optimization processingmodule 180 and/or the financial service provider system 105 operatinglogic and functionality are provided below with reference to FIGS. 2-5.

With continued reference to the optimization computer 160, the one ormore I/O interfaces 166 may facilitate communication between theoptimization computer 160 and one or more input/output devices; forexample, one or more user interface devices, such as a display, akeypad, a mouse, a pointing device, a control panel, a touch screendisplay, a remote control, a microphone, a speaker, etc., thatfacilitate user interaction with the optimization computer 160. Forexample, one or more service provider employees or potentially evenfinancial institution employees may interact with the optimizationcomputer 160 in order to establish various parameters associated withvarious operational aspects, to review optimization results, and/or toreview various logs and/or reports. The one or more network interfaces168 may facilitate connection of the optimization computer 160 to one ormore suitable networks, for example, the network(s) 144, 145 illustratedin FIG. 1, or local area network(s) within the financial serviceprovider system 105. In this regard, the optimization computer 160 mayreceive and/or communicate information to other components of the system100, such as the databases 110 a-n (either directly or via one or morecomputers managing databases 110 a-n) and/or the financial institutionsystems 106. As desired, any number of Web pages, interface screens,and/or other presentations (e.g., graphical user interfaces, etc.) maybe provided or presented to a financial institution system 106 via thenetwork 145.

The databases 110 a-n can provide a wide variety of account and/ortransactional data associated with customers of any number of financialinstitutions. In one example embodiment of the invention, the databases110 a-n may include one or more of a deposit account database 110 a, acredit account database 110 b, a loan account database 110 c, and/or anynumber of databases 110 n associated with other information. The depositaccount database 110 a may include information associated with anynumber of deposit accounts that one or more customers have with anynumber of the financial institutions. A wide variety of informationassociated with a deposit account may be stored as desired, includingbut not limited to, account identification information (e.g., an accountnumber, a financial institution identifier, etc.), customeridentification information (e.g., identifying information for a customerassociated with the deposit account, etc.), account type information(e.g., savings account, checking account, etc.), account parameterinformation (e.g., an interest rate associated with the account, aminimum balance associated with the account, etc.), account balanceinformation, historical account balance information, (e.g., a monthlyaccount balance over a predetermined historical period of time), and/orinformation associated with fees incurred in association with thedeposit account (e.g., information associated with fees incurred over apredetermined historical period of time, etc.). As desired, a widevariety of scores, factors, and/or other derived values may additionallybe associated with an account and/or a customer.

The credit account database 110 b may include information associatedwith any number of credit accounts that one or more customers have withany number of the financial institutions. A wide variety of informationassociated with a credit account may be stored as desired, including butnot limited to, account identification information (e.g., an accountnumber, a financial institution identifier, etc.), customeridentification information (e.g., identifying information for a customerassociated with the credit account, etc.), account type information(e.g., a type of credit card provider associated with the creditaccount, account status information, etc.), account parameterinformation (e.g., an interest rate associated with the account, etc.),account balance information, historical account balance information,(e.g., a monthly account balance over a predetermined historical periodof time), and/or information associated with interest collected inassociation with the credit account (e.g., information associated withaverage interest and/or total interest incurred over a predeterminedhistorical period of time, etc.).

The loan account database 110 c may include information associated withany number of loan accounts that one or more customers have with anynumber of the financial institutions. A wide variety of informationassociated with a loan account may be stored as desired, including butnot limited to, account identification information (e.g., an accountnumber, a financial institution identifier, etc.), customeridentification information (e.g., identifying information for a customerassociated with the loan account, etc.), account type information (e.g.,an identifier of a type of loan account, account status information,etc.), an original principal amount, a loan inception data, a term ofthe loan, an interest rate associated with the loan, an amount ofremaining interest to be paid, historical payment history information,and/or information associated with fees incurred in association with theloan (e.g., information associated with late fees incurred over apredetermined historical time period, etc.).

The other databases 110 n may include a wide variety of other data thatis accessible by the financial service provider system 105, such asother financial information associated with customers, algorithms and/ormodels utilized to provide optimization services, and/or various rulesand/or preferences associated with financial institutions. In certainembodiments, the other databases 110 n may include electronic billpresentment and/or payment (EBPP) information for the customers. Otherexamples of information that may be stored in another database 110 ninclude, but are not limited to, customer loyalty information, customerrewards information (e.g., accumulated points, etc.), credit bureauinformation, and/or customer identity information.

As desired, one or more of the databases 110 a-n may be maintained by afinancial institution system 106. Alternatively, at least one of thedatabases 110 a-n may be maintained by a third-party service provider ordata source. Additionally, as desired, separate databases may beassociated with different financial institutions. For example, thefinancial service provider system 105 may be configured to provide NSFoptimization services for a plurality of different financialinstitutions, and a plurality of respective sources of information maybe accessed in order to carry out these services.

Although not described or illustrated in detail, each financialinstitution computer 140 may be configured in the same or similar manneras described for the financial service provider system 105. For example,financial institution computer 140 may include one or moreprocessor-based computers operable to store and executecomputer-executable instructions, each having one or more processors,memories, I/O interfaces, network interfaces, operating systems, datafiles, databases or other data storage means, DBMS, host modules andother operating logic to perform some or all of the same or similarfunctions as are described herein with reference to the financialservice provider system 105 (e.g., optimization computer 160).

The networks 144, 145 may include any number of telecommunication and/ordata networks, whether public, private, or a combination thereof,including but not limited to, the Internet, a local area network, a widearea network, an intranet, intermediate handheld data transfer devices,public switched telephone networks, and/or any combination thereof andmay be wired and/or wireless. The networks 144, 145 may also allow forsynchronous, including real-time, and/or asynchronous, including batch,transactions to be transmitted thereover. Due to network connectivity,various methodologies described herein may be practiced in the contextof distributed computing environments. Although the system 100 is shownfor simplicity as including networks 144, 145, it is to be understoodthat any other network configuration is possible, which may optionallyinclude a plurality of networks for each of networks 144, 145, each withdevices such as gateways and routers, for providing connectivity betweenor among networks.

Those of ordinary skill in the art will appreciate that the system 100shown in and described with respect to FIG. 1 is provided by way ofexample only. Numerous other operating environments, systemarchitectures, and device configurations are possible. Other systemembodiments can include fewer or greater numbers of components and mayincorporate some or all of the functionality described with respect tothe system components shown in FIG. 1. Accordingly, embodiments of theinvention should not be construed as being limited to any particularoperating environment, system architecture, or device configuration.

II. Operational Overview

In various embodiments of the invention, a wide variety of NSFoptimizations may be performed. These NSF optimizations may includereactive and/or proactive NSF optimizations. For example, a best nextaction may be reactively determined based upon the identification of anNSF event or condition. As another example, an overdraft limit amount orother parameter may be proactively determined in order to address apotential NSF condition. FIG. 2 illustrates a flow diagram of an examplemethod 200 for reactively recommending and/or implementing an actionassociated with an NSF condition, according to an illustrativeembodiment of the invention. The method 200 may be performed by asuitable financial service provider system and/or associatedoptimization computers, such as the financial service provider system105 and/or optimization computers 160 illustrated in FIG. 1. The method200 may begin at block 205.

At block 205, a customer may be identified for an NSF optimization. Incertain embodiments of the invention, the customer may be identifiedbased upon the identification of an NSF condition or an NSF event. Forexample, a suitable financial institution system, such as the financialinstitution system 106 illustrated in FIG. 1, may provide informationassociated with an NSF condition, such as a returned check, a faileddebit transaction, or other NSF condition, to the financial serviceprovider system 105. The customer may then be identified based at leastin part upon the received information associated with the NSF event. Forexample, received customer identification information (e.g., customername, etc.) may be utilized to identify the customer. As anotherexample, received account identification information (e.g., an accountnumber, etc.) may be evaluated, and a customer associated with theaccount may be identified.

At block 210, a customer segment for the identified customer may bedetermined. In certain embodiments, a customer may be assigned to agroup or segment of similar customers. In one example embodiment, acustomer segment may be a customer classification associated with avalue of the customer to the financial institution. A wide variety ofdifferent customer segments and/or types of customer segments may beutilized as desired in various embodiments of the invention. Thesevarious customer segments may take a wide variety of different factorsand/or considerations into account, such as the respective incomesgenerated by the customers for the financial institution. In certainembodiments, both interest income and non-interest income (e.g., fees,etc.) associated with a customer may be considered when determining acustomer segment. A wide variety of different criteria associated withvarious customer accounts may be evaluated in order to determineinterest and/or non-interest income for the customer. These criteria mayinclude any number of current account attributes and/or historicalaccount attributes, such as information associated with current accountbalances, historical account balance information, interest rateinformation, and/or information associated with fees. Once evaluated,the customer may be assigned to a suitable customer segment. Forexample, determined values for interest and non-interest income may beutilized to assign the customer to a customer segment.

One example of an evaluation that may be utilized to assign a customerto a customer segment will now be described. Information associated withone or more customer accounts with the financial institution may beobtained. For example, account information may be obtained from one ormore suitable financial institution systems 106, such as one or more“core account” systems associated with the financial institutions.Additionally, as desired, a wide variety of suitable models, formulas,and/or other information utilized to evaluate the customer accounts(e.g., industry-standard net interest margin values for various accounttypes, etc.) may be obtained from one or more suitable data sources,such as the financial institution systems 106 and/or various third-partydata sources. A wide variety of techniques may be utilized to obtain thedesired information. For example, data may be periodically (e.g., once aday, once a week, once a month, etc.) received from a data sourceutilizing either a “push” (i.e., received without being requested) or a“pull” (i.e., received in response to a request) method, and at least aportion of the received data may be stored for subsequent processing. Asanother example, data may be obtained in a “just-in-time” manner whendesired for processing. For example, an optimization computer 160 mayrequest data during the determination of a customer segment. As anotherexample, a financial institution computer 140 may communicate data tothe optimization computer 160 based upon the identification of an NSFcondition.

As desired, the data evaluated in a customer segment determination mayinclude data associated with a wide variety of different customeraccounts, such as one or more credit accounts, one or more depositaccounts, and/or one or more loan accounts that the customer has withthe financial institution. With respect to credit accounts, it may bepossible for the optimization computer 160 to obtain and evaluateindividual credit account information. For embodiments in whichindividual credit account information is not available, the informationthat may be evaluated for a credit account includes, but is not limitedto, an account type, a current monthly balance, monthly balances thathave been collected for a predetermined historical period of time (e.g.,the last six months, the last year, etc.), and/or a net interest margin,such as a net interest margin derived from applicable industrystandards. For example, an industry average for interest income derivedfrom a credit card customer may be utilized to determine a net interestmargin for the credit account. In embodiments in which individual creditaccount information is available, it may be possible to perform a moredetailed evaluation of the credit account. For example, the averageinterest incurred for a predetermined historical period of time, acurrent account balance, and/or an applicable interest rate for theaccount may be evaluated.

Examples of data that may be evaluated for a deposit account include,but are not limited to, an account type, a monthly balance for apredetermined historical period of time (e.g., the last six months, thelast year, etc.), a net interest margin, and/or fees incurred for apredetermined historical period of time (e.g., account maintenance fees,NSF fees, etc.). In certain embodiments, the net interest margin may bederived from applicable industry standards. For example, an industryaverage for interest income derived from financial institutioninvestment of funds on deposit may be utilized to determine a netinterest margin. Examples of data that may be evaluated for a loanaccount include, but are not limited to, an original principal amountfor the loan, a loan inception data, a term of the loan, an interestrate for the loan, an amount of remaining interest to be paid,information associated with additional principal payments made by theconsumer, information associated with pre-paid interest payments made bythe consumer, information associated with fees (e.g., late charges)incurred over a predetermined historical period of time (e.g., the lastsix months, the last year, the life of the loan, etc.), and/orinformation associated with escrow payments (e.g., float income earnedfrom escrow accounts, etc.).

Once customer account data has been obtained (or accessed from memory),at least a portion of the customer account data may be evaluated inorder to determine a customer segment for the customer. For example,interest income and non-interest income for the customer may bedetermined based upon an analysis of the customer account data. A widevariety of different types of income determination may be made, such ashistorical determinations over a period of time, average incomedeterminations, and/or projected income determinations. The interestincome and non-interest income may then be utilized to assign thecustomer to an appropriate customer segment or customer value group. Asmentioned above, a wide variety of different customer segments may beutilized as desired in various embodiments of the invention. FIG. 3illustrates a visual diagram 300 of example customer segments that maybe utilized. With reference to FIG. 3, four customer segments 305, 310,315, 320 may be available for customer assignment. Each of thesecustomer segments 305, 310, 315, 320 may be associated with differentcombinations of interest and non-interest income amounts.

A first customer segment 305 may be utilized for customers associatedwith relatively high interest income and relatively low non-interestincome. A customer situated in the first customer segment 305 (referredto as a first segment customer) typically generates substantial interestincome for the financial institution as a result of maintainingrelatively high account balances and/or as a result of generatingrelatively high credit and/or loan interest. Additionally, a firstsegment customer is typically associated with a relatively lowoccurrence of NSF conditions, thereby resulting in relatively lownon-interest income. As a result of the account relationship(s) with thefinancial institution, a first segment customer is also typically a“sticky” customer for the financial institution. Thus, it may berelatively unlikely that a first segment customer will attrite toanother financial institution. Additionally, a first segment customermay typically exhibit sensitivity to service charges and/oraccount-related fees, such as NSF fees.

A second customer segment 310 may be utilized for customers associatedwith relatively high interest income and relatively high non-interestincome. The second customer segment 310 may be the highestrevenue-generating segment of financial institution customers. Examplecustomers situated in the second customer segment 310 (referred to assecond segment customers) may maintain relatively high account balancesand/or generate substantial credit and/or loan interest, and incur arelatively high number of account-related fees (e.g., NSF fees, etc.). Asecond segment customer is typically a “sticky” customer for thefinancial institution. Thus, it may be relatively unlikely that a secondsegment customer will attrite to another financial institution.Additionally, a second segment customer may typically exhibit lesssensitivity to service charges and/or account-related fees, such as NSFfees, than a first segment customer.

A third customer segment 315 may be utilized for customers associatedwith relatively low interest income and relatively low non-interestincome. The third customer segment 315 may be the lowestrevenue-generating segment of financial institution customers. Acustomer situated in the third customer segment 315 (also referred to asa third segment customer) typically maintains relatively low accountbalances and/or typically does not generate substantial credit and/orloan interest. Additionally, a third segment customer typically incurs alower number of account-related fees, such as NSF fees. As a result ofthe relatively modest account relationships, a third segment customertypically has relatively low “stickiness” to the financial institutionand may be relatively likely to attrite.

A fourth customer segment 320 may be utilized for customers associatedwith relatively low interest income and relatively high non-interestincome. A customer situated in the customer segment 320 (also referredto as a fourth segment customer) typically maintains relatively lowaccount balances and/or typically does not generate substantial creditand/or loan interest. Additionally, a fourth segment customer typicallyincurs a relatively high number of account-related fees, such as NSFfees. As a result of the relatively modest account relationships, athird segment customer typically has relatively low “stickiness” to thefinancial institution. These modest relationships are typicallyinsufficient to overcome any negativity associated with account-relatedfees. Accordingly, a fourth segment customer may be relatively likely toattrite, and the generation of fees may trigger the attrition.

In certain embodiments, each of the example customer segments 305, 310,315, 320 may be associated with respective threshold values for interestand non-interest income. For example, interest income that exceeds acertain interest income threshold value (i.e., “high” interest income)may result in a customer being assigned to either the first customersegment 305 or the second customer segment 310. Otherwise, the customermay be a relatively “low” interest income customer that is assigned toeither the third customer segment 315 or the fourth customer segment320. As another example, non-interest income that exceeds a certainnon-interest income threshold value (i.e., “high” non-interest income)may result in a customer being assigned to either the second customersegment 310 or the fourth customer segment 320. Otherwise, the customermay be a relatively “low” non-interest income customer that is assignedto either the first customer segment 305 or the third customer segment315.

The customer segments 305, 310, 315, 320 illustrated in FIG. 3 areprovided by way of example only. As desired, less than or more than thecustomer segments illustrated in FIG. 3 may be utilized. For example,segments may be provided for any number of combinations of high, medium,and low interest and/or non-interest income. Additionally, as desired,any number of other evaluations and/or determinations may be utilized toassign customers to segments. For example, customers may be scored inaccordance with a wide variety of different factors, and the customersmay be assigned to segments based at least in part upon the scores.

With continued reference to block 210 of FIG. 2, a wide variety ofsuitable methods and/or techniques may be utilized to assign a customerto a customer segment. As one simplified example, information associatedwith credit and/or deposit accounts may be evaluated in order todetermine interest income for the customer. Additionally, depositaccount information may be evaluated in order to determine non-interestincome (e.g., NSF fees, etc.) for the customer. For each account,monthly interest income may be approximated utilizing any number ofsuitable techniques. Utilizing a deposit account as an example, anaverage monthly balance may be calculated or determined for the accountby averaging one or more actual monthly balances for a predeterminedhistorical time period. An industry standard net interest margin value,or a financial institution's actual product level net interest marginvalue, may then be multiplied or otherwise combined with the averagemonthly balance in order to calculate interest income for the depositaccount. Utilizing a credit account as another example, an average ofactual monthly interest incurred for a predetermined historical periodof time may be calculated. Additionally or alternatively, a predictionof monthly interest may be determined based upon a current accountbalance, a percentage of the account balance that is typically carriedforward (e.g., a percentage determined from historical data, etc.), andan applicable interest rate. As an example of determining non-interestincome, historical fee data for a deposit account may be evaluated. Incertain embodiments, the total fees (e.g., NSF fees, stop check fees,wire transfer fees, check reorder fees, overdraft protection chargefees, account maintenance fees, etc.) for a previous month may bedetermined. Certain fees may be recurring fees (e.g., accountmaintenance fees, etc.) and other fees may be one-time fees or feesgenerated based upon the identification of an event (e.g., NSF fees,stop check fees, etc.). In other embodiments, a monthly average of feesover a predetermined historical time period (e.g., three months, sixmonths, a year, etc.) may be determined.

Once the various accounts of the customer have been evaluated, a totalinterest income value and a total non-interest income value may bedetermined for the customer. As an example of determining a totalinterest income value, the respective interest income values for each ofthe customer's credit and deposit accounts may be summed together.Similarly, as an example of determining a total non-interest incomevalue, the respective non-interest income values for each of thecustomer's deposit accounts may be summed together. In certainembodiments, historical data that predates current account periods(e.g., data that is greater than one month or 30 days old, etc.) may beutilized in a determination of the total interest income value and/orthe total non-interest income value. The determined total interest andnon-interest income values may then be compared to one or more thresholdvalues and/or ranges of values associated with assigning the customer toa customer segment.

A wide variety of different threshold values may be utilized as desired.For example, given the four customer segments set forth in FIG. 3, atotal interest income threshold value “X” and a total non-interestincome threshold value “Y” may be utilized. The determined totalinterest income and non-interest income values for the customer may thenbe evaluated utilizing the two threshold values “X” and “Y.” Based atleast in part upon the evaluation, the customer may be assigned to oneof the four customer segments illustrated in FIG. 3. Example equationsfor identifying a customer segment for the customer are set forth below:

-   -   If (total interest income>“X”) AND (total non-interest        income<“Y”), then customer is assigned to segment “1”    -   If (total interest income>“X”) AND (total non-interest        income>“Y”), then customer is assigned to segment “2”    -   If (total interest income<“X”) AND (total non-interest        income<“Y”), then customer is assigned to segment “3”    -   If (total interest income<“X”) AND (total non-interest        income>“Y”), then customer is assigned to segment “4”

In certain embodiments, once a customer segment has been determined forthe customer, an indicator of the customer segment may be stored. Inthis regard, the determined customer segment may be utilized inassociation with subsequent processing for the customer. For example,the customer segment may be utilized to process subsequently identifiedNSF conditions or potential NSF conditions. As desired in certainembodiments, a customer segment assignment for a customer may bereevaluated on a periodic or event-driven basis. For example,account-related information for a customer may be periodicallyreevaluated (e.g., once a month, once every three months, etc.), andupdates to the customer segment assignment may be performed. As anotherexample, a customer segment assignment may be reevaluated based at leastin part upon the identification of one or more predetermined conditions,such as the opening of a new account, the change of an account status,or the incidence of a predetermined number of NSF fees.

The example set forth above for calculating interest and non-interestincome and determining a customer segment is a relatively simple exampleand is not intended to be limiting. A wide variety of other factorsand/or processing techniques may be utilized as desired in variousembodiments of the invention. For example, interest and/or non-interestincome associated with loan accounts may be determined. As anotherexample, one or more models may be utilized to determine or calculateexpected interest and/or non-interest income.

Following the determination of a customer segment at block 210,operations may continue at block 215. At block 215, an attrition riskmay be determined for the customer. The determination of the attritionrisk may be independent of an attrition risk associated with a customersegment for the customer. In certain embodiments, one or more predictivemodels may be invoked and/or utilized in order to determine an attritionrisk for the customer. The attrition risk may be expressed, for example,as a probability or a score within an applicable range. The one or morepredictive models utilized to evaluate the customer may be identifiedand/or selected based at least in part upon a wide variety of differentfactors, such as one or more customer attributes. As one example, apredictive model may be identified based upon the tenure of the customerwith the financial institution. A few examples of predictive models thatmay be utilized are described in U.S. patent application Ser. No.12/893,822, filed Sep. 29, 2010 and entitled “Systems and Methods forCustomer Value Optimization Involving Product/Service Optimization,” andin U.S. patent application Ser. No. 12/893,841, filed Sep. 29, 2010 andentitled “Systems and Methods for Customer Value Optimization InvolvingRelationship Optimization.” Each of these applications is incorporatedby reference herein in its entirety.

A wide variety of different types of predictive models may be utilized,such as logistic regression models, neural network models, and/or othertypes of models. In certain embodiments, a model may be generated byevaluating historical data associated with financial institutioncustomers, including historical data associated with customers thatclosed accounts with the financial institution. For example, historicaldata may be obtained from the core account systems of one or morefinancial institutions, and the historical data may be processed inorder to generate an attrition model. The process of devising anattrition model may involve the identification of one or more dataattributes that provide a best indication of customer attrition and/ordetermining appropriate weightings of the attributes and/orrelationships between the attributes. In this regard, customer valuesfor the attributes may be provided to the model in order to predictcustomer attrition. As desired, a model may be specific to a particularfinancial institution or, alternatively, the model may have a scope thatencompasses a plurality of financial institutions. Additionally, a modelmay be adjusted based upon the presence of new data. For example, amodel may be periodically adjusted, or a model may be adjusted followingthe identification of a predetermined event.

Once generated, a predictive model may be utilized to evaluate dataassociated with a customer in order to determine an attrition riskassociated with the customer. In certain embodiments, historical accountdata for the customer, such as relatively recent transactional data fora predetermined past period, may be collected, and at least a portion ofthe historical account data may be provided to and/or run through apredictive model. In certain embodiments, data may be periodicallyobtained (e.g., once a day, once a week, once a month, etc.) from afinancial institution system 106, and at least a portion of the data maybe stored for subsequent evaluation utilizing the model. In otherembodiments, data may be acquired in a “just-in-time” manner whendesired for processing. The predictive model may be utilized to evaluateany number of components of the data. For example, the predictive modelmay identify and evaluate attributes of the data that have beendetermined to be significant indicators of attrition risk. In thisregard, the predictive model may calculate an attrition risk for thecustomer. In certain embodiments, the predictive model may evaluateaccount activity patterns irrespective of the actual or potentialincidence of fees. As a result of examining a variety of accountrelationships and activity other than simply the charging of fees, apredictive model may identify an attrition risk that may otherwise goundetected.

A wide variety of different formats may be utilized to represent adetermined attrition risk. For example, an attrition risk may berepresented as a probability value in the range of zero to one or as ascore within some other range of possible values. In certainembodiments, once an attrition risk has been determined for thecustomer, the determined attrition risk may be stored. In this regard,the determined attrition risk may be utilized in association withsubsequent processing for the customer. For example, the attrition riskmay be utilized to process subsequently identified NSF conditions orpotential NSF conditions. As desired in certain embodiments, anattrition risk for a customer may be periodically reevaluated. Forexample, account-related information for a customer may be periodicallyreevaluated (e.g., once a month, once every three months, etc.)utilizing one or more appropriate models, and the attrition risk may beupdated. In other embodiments, an attrition risk may be reevaluatedbased at least in part upon the identification of one or morepredetermined conditions, such as the opening of a new account, thechange of an account status, or the incidence of a predetermined numberof NSF fees.

At block 220, a customer tolerance or capacity for absorbing an NSF fee,hereinafter referred to as a customer tolerance, may be determined orcalculated. A wide variety of suitable formats may be utilized torepresent the customer tolerance. For example, in certain embodiments,the customer tolerance may be represented by a ratio of cumulative NSFfees to cumulative deposits for some period of time across a pluralityof financial institution accounts for the customer. As desired, theratio may be determined by evaluating some amount of historical data. Adetermined ratio may be a measure of the customer's ability to absorbfees. The higher the value of the ratio, the more difficult it may befor the customer to absorb a fee, and therefore, the greater thelikelihood of an account closure.

A wide variety of suitable methods and/or techniques may be utilized asdesired to calculate a customer tolerance for the customer. In certainembodiments, historical account data for the customer, such ashistorical deposit and fee data, may be collected, and at least aportion of the historical account data may be evaluated. In certainembodiments, data may be periodically obtained (e.g., once a day, once aweek, once a month, etc.) from a financial institution system 106, andat least a portion of the data may be stored for subsequent evaluation.In other embodiments, data may be acquired in a “just-in-time” mannerwhen desired for evaluation. Once obtained, the data may be evaluatedutilizing any number of suitable formulas that calculate a customertolerance, such as the formula set forth in equation one (1) below:

$\begin{matrix}{{{Customer}_{—}{Tolerance}_{ij}} = \frac{\sum\limits_{t = {L\; 1}}^{L\; 2}\; {{NSF}_{—}{Fees}_{ijt}}}{\left\lbrack \frac{\left( {\sum\limits_{t = {C\; 1}}^{C\; 2}\; {Credits}_{ijt}} \right)}{\left( {{C\; 2} - {C\; 1}} \right)} \right\rbrack}} & (1)\end{matrix}$

With respect to equation (1), the customer is represented by thevariable “i”, time is represented by the variable “j”, L1 and L2respectively represent the start and end points for evaluating NSF fees,and C1 and C2 respectively represent the start and end points forevaluating credits or deposits. Accordingly, equation (1) may beutilized to calculate a ratio of cumulative NSF fees to cumulativedeposits (i.e., credits) across any number of accounts for any suitablepredetermined historical time period. The determined ratio may be anindicator of the ability of the customer to absorb an additional NSFfee.

In certain embodiments, once a customer tolerance has been determinedfor the customer, the determined customer tolerance may be stored. Inthis regard, the determined customer tolerance may be utilized inassociation with subsequent processing for the customer. For example,the customer tolerance may be utilized to process subsequentlyidentified NSF conditions or potential NSF conditions. As desired incertain embodiments, a customer tolerance for a customer may beperiodically reevaluated. For example, account-related information for acustomer may be periodically reevaluated (e.g., once a month, once everythree months, etc.), and the customer tolerance may be updated. In otherembodiments, a customer tolerance may be reevaluated based at least inpart upon the identification of one or more predetermined conditions,such as the opening of a new account, the change of an account status,or the incidence of a predetermined number of NSF fees.

Following the determination at block 220 of a customer tolerance forabsorbing an NSF fee, one or more business rules to execute may beidentified based on one or more of the determined customer segment,attrition risk, and/or customer tolerance, as well as potentially one ormore other data attributes associated with the customer. In certainembodiments, the use of these factors by the business rules may producea result that may be utilized to determine an action for processing theNSF condition. A wide variety of different business rules may beexecuted as desired in various embodiments. The business rules mayinclude default business rules and/or business rules (e.g., customizedbusiness rules) specified by a client of the financial service provider,such as a financial institution. A business rule may apply to any numberof the factors described in blocks 210, 215, and 220. Additionally, asdesired, a business rule may take additional factors into consideration.In certain embodiments, a plurality of business rules may be applicableto the relevant factors, and a suitable hierarchy of business rules maybe established and utilized to select applicable business rules and/oran order for implementing business rules. Additionally, in certainembodiments, various rules may be associated with different financialinstitution objectives (e.g., maximization of non-interest income,retention of customers, etc.). Accordingly, it may be possible that aplurality of rules are applicable, and one or more rules may beidentified and/or selected in accordance with the financial institutionobjectives.

At block 225, a determination may be made as to whether a customizedbusiness rule is currently applicable. For example, a determination maybe made as to whether a client-specified business rule is applicable toan NSF condition involving any number of the determined factors (e.g.,the determined customer segment value, the determined attrition risk,the determined customer tolerance, etc.). Assuming a determined customersegment of “X”, a determined attrition risk score of “Y”, and adetermined customer tolerance of “Z”, a determination may be made as towhether a client-specified business rule is applicable to the determinedvalues. If it is determined at block 225 that a customized orclient-specified business rule is applicable, then operations maycontinue at block 230. At block 230, an identification of a businessrule to be executed may be set to the customized business rule.Operations may then continue at block 240 described in greater detailbelow.

If, however, it is determined at block 225 that a customized orclient-specified business rule is not applicable, then operations maycontinue at block 235. At block 235, an applicable default or financialservice provider system business rule may be identified, and theidentification of the business rule to be executed may be set to thedefault business rule. A wide variety of default business rules may beutilized as desired in various embodiments of the invention. In certainembodiments, default business rules may be generated by the financialservice provider system 105 based upon an analysis of historicalcustomer data (e.g., attrition data, etc.) for any number of customersover a predetermined period of time (e.g., the last six months, the lastyear, etc.). During the analysis, suitable cutoff points and/orthresholds may be identified for attrition risk and/or customertolerance. In certain embodiments, respective cutoff points and/orthresholds may be determined for different customer segments. Asdesired, default business rules may be subsequently modified byfinancial institution clients of the financial service provider. In thisregard, client preferences that differ from default assumptions may becaptured. Following the setting of a default business rule as anapplicable business rule at block 235, operations may continue at block240.

Any number of business rules may be established and/or utilized asdesired in various embodiments of the invention. As desired, a givenbusiness rule may emphasize a desired factor or result. In certainembodiments, a business rule may emphasize a desired result given aparticular client objective or goal. For example, a business rule may beintended to maximize non-interest income for a financial institutionclient. As another example, a business rule may be intended to minimizeattrition risk. A wide variety of different business rules may beassociated with these and other objectives. Additionally, in certainembodiments, a client may specify whether a specific or a defaultbusiness rule will be utilized. For example, a client may specify that aparticular business rule will be utilized for a given analysis of one ormore actual and/or potential NSF conditions. In certain embodiments, anNSF condition may be evaluated a plurality of times utilizing differentbusiness rules. In this regard, various options for a next best actionmay be determined.

At block 240, which may be reached from either block 230 or block 235,the applicable business rule may be executed or applied in order todetermine a best next action (“BNA”) recommendation. In certainembodiments, the execution of a business rule produces a value that maybe associated with a recommended BNA. An example of a business rule isset forth below:

-   -   IF (segment=“1”) AND (attrition risk>0.7) AND (customer        tolerance>0.01), THEN rule result=“X”

Following the execution of the business rule to produce the result of“X,” the result may be utilized to determine a BNA to be recommended inassociation with the identified NSF condition. For example, the resultmay be mapped to a previously stored BNA utilizing a suitable mapping orlookup table. A wide variety of different BNAs may be utilized asdesired in various embodiments. Given the particular mix of conditionsassociated with the example business rule, the intent or objective maybe to retain a customer that has relatively high interest income.Accordingly, the recommended BNA may be an action to “waive an NSF feeif requested by the customer.” In such a situation, the long-termbenefits of the high interest income may outweigh the loss of incomethat would be generated by the NSF fee. Other business rules may beapplicable to other customer segments, other attrition risks, and/orother customer tolerance levels. Additionally, these business rules maybe associated with goals other than customer retention, such asmaximizing NSF fee income or maximizing total projected income for afuture period of time. Examples of other recommended BNAs include, butare not limited to, a recommendation to do nothing and allow an NSF feeto be charged, a recommendation to extend the customer an offer for ashort-term loan or an easy advance in order to cover the NSF situation,a recommendation to waive the NSF fee if requested, a recommendation todiscount the NSF fee if requested, a recommendation to proactively(i.e., without request) waive the NSF fee, and/or a recommendation toproactively discount the NSF fee.

At block 245, a BNA recommendation may be generated and/or executed. Forexample, a message including information associated with a recommendedBNA may be communicated to a financial institution computer 140. Incertain embodiments, the message may be communicated in response to areceived request to determine a recommended BNA. As another example,implementation or execution of the recommended BNA may be instructed.For example, an instruction to implement a recommended BNA may becommunicated to a suitable financial institution computer 140.

At block 250, a determination may be made as to whether any additionalNSF conditions are to be evaluated and/or handled. If it is determinedat block 250 that an additional NSF condition is to be evaluated, thenoperations may continue at block 205, in which a customer associatedwith a next NSF condition may be identified. If, however, it isdetermined at block 250 that no additional NSF conditions are to beevaluated, then operations may end.

The method 200 may end following block 250.

FIG. 2 describes an example process for reactively determining and/orimplementing a recommended BNA in response to an identified NSFcondition. Embodiments of the invention may also be utilized toproactively provide NSF optimization. For example, a respectiveoverdraft limit amount may be determined for each of any number ofdemand deposit accounts in a proactive or anticipatory manner. Asdesired, any number of customers may be evaluated in order to determinerespective overdraft limits. In this regard, a financial institution mayestablish tailored limits to various customers and/or groups ofcustomers. As desired, these limits may be based on perceived riskand/or profit potential associated with the various customers. Accordingto an aspect of the invention, a proactive NSF optimization for acustomer may take a wide variety of customer factors into consideration,such as the customer's relationships with the financial institution, thevalue of the customer to the financial institution, and/or an attritionrisk for the customer. In certain embodiments, these factors may beevaluated in a holistic manner in order to account for the totality ofthe customer's relationships with the financial institution.

FIG. 4 illustrates a flow diagram of an example method 400 forproactively recommending and/or implementing an action associated with apotential NSF condition, according to an illustrative embodiment of theinvention. More specifically, FIG. 4 illustrates a flow diagram of anexample method for determining overdraft limits for one or morefinancial institution customers. The method 400 may be performed by asuitable financial service provider system and/or associatedoptimization computers, such as the financial service provider system105 and/or optimization computers 160 illustrated in FIG. 1. The method400 may begin at block 405.

At block 405, a customer may be identified for an NSF optimization. Awide variety of suitable methods and/or techniques may be utilized toidentify a customer. For example, a request to perform an NSFoptimization may be received from a financial institution, and thecustomer may be identified by evaluating information included in therequest. As another example, identification information may be obtainedfor a plurality of different customers, and one or more individualcustomers may be identified for processing. For example, a batch processmay be performed that processes individual customers.

Once a customer has been identified at block 405, operations maycontinue at block 410. At block 410, a customer segment may beidentified for the customer. The operations that may be performed atblock 410 to identify a customer segment may be similar to thosedescribed above with reference to block 210 of FIG. 2. At block 415, anattrition risk may be determined for the customer. The operations thatmay be performed at block 415 to determine an attrition risk may besimilar to those described above with reference to block 215 of FIG. 2.At block 420, a customer tolerance for absorbing an NSF fee may beidentified for the customer. The operations that may be performed atblock 420 to determine a customer tolerance may be similar to thosedescribed above with reference to block 220 of FIG. 2. Additionally, oneor more business rules to execute may be identified for the customer ina similar manner as that described above with reference to FIG. 2.

At block 425, a determination may be made as to whether a customizedbusiness rule is currently applicable. For example, a determination maybe made as to whether a client-specified business rule is applicable toany number of the determined factors associated with the customer (e.g.,the determined customer segment value, the determined attrition risk,the determined customer tolerance, etc.). Assuming a determined customersegment of “X”, a determined attrition risk score of “Y”, and adetermined customer tolerance of “Z”, a determination may be made as towhether a client-specified business rule is applicable to the determinedvalues. If it is determined at block 425 that a customized orclient-specified business rule is applicable, then operations maycontinue at block 430. At block 430, an identification of a businessrule to be executed may be set to the customized business rule.Operations may then continue at block 440 described in greater detailbelow.

If, however, it is determined at block 425 that a customized orclient-specified business rule is not applicable, then operations maycontinue at block 435. At block 435, an applicable default or financialservice provider system business rule may be identified, and theidentification of the business rule to be executed may be set to thedefault business rule. A wide variety of default business rules may beutilized as desired in various embodiments of the invention. In certainembodiments, default business rules may be generated by the financialservice provider system 105 based upon an analysis of historicalcustomer data (e.g., overdraft data, account balance data, attritiondata, etc.) for any number of customers over a predetermined period oftime (e.g., the last six months, the last year, etc.). During theanalysis, suitable cutoff points and/or thresholds may be identified forattrition risk and/or customer tolerance. In certain embodiments,respective cutoff points and/or thresholds may be determined fordifferent customer segments. As desired, default business rules may besubsequently modified by financial institution clients of the financialservice provider. In this regard, client preferences that differ fromdefault assumptions may be captured. Following the setting of a defaultbusiness rule as an applicable business rule at block 435, operationsmay continue at block 440.

Any number of business rules may be established and/or utilized asdesired in various embodiments of the invention. Additionally, thebusiness rules utilized in association with establishing overdraftlimits may be different from the business rules utilized to processidentified NSF conditions. In certain embodiments, a business rule maybe utilized to determine a base overdraft amount for a customer. Forexample, a business rule may be utilized to identify a base overdraftamount for a customer within a given segment having a given attritionrisk and customer tolerance. As desired, the base overdraft amount maybe adjusted utilizing one or more additional business rules. In otherwords, one or more variable components for an overdraft amount may bedetermined utilizing one or more additional business rules, and thevariable component(s) may be utilized to adjust a base overdraft amount.In this regard, individualized overdraft amounts may be tailored tospecific customers.

At block 440, which may be reached from either block 430 or block 435,the applicable business rule(s) may be executed or applied in order todetermine an overdraft limit for the customer. For example, in certainembodiments, a value or result generated by the application of thebusiness rule(s) may be mapped to an overdraft limit value. As desired,a range of business rule results may be mapped to a single overdraftlimit value. As another example, application of the business rule(s) mayproduce the overdraft limit for a customer. One example of theoperations that may be performed to determine an overdraft limit for acustomer is described in greater detail below with reference to FIG. 5.

At block 445, an overdraft limit recommendation may be generated and/orexecuted. For example, a message or notification including informationassociated with a determined overdraft limit may be communicated to afinancial institution computer 140. As desired, a single message may beutilized to provide recommended overdraft limits for a plurality ofcustomers. In certain embodiments, the message may be communicated inresponse to a received request to determine one or more recommendedoverdraft limits. As another example, implementation or execution of therecommended overdraft limit may be instructed. For example, aninstruction to set, adjust, or establish respective overdraft limits forone or more customers and/or customer accounts may be communicated to asuitable financial institution computer 140. Other actions may be takenas desired based upon the identification of an overdraft limitrecommendation. For example, a customer may be approved for a short-termloan that falls within a determined overdraft limit.

At block 450, a determination may be made as to whether any additionalcustomers are available for performing NSF optimization. If it isdetermined at block 450 that an additional customer is available, thenoperations may continue at block 405, and a next customer may beidentified for evaluation. If, however, it is determined at block 450that no additional customers are available, then operations may end.

The method 400 may end following block 450.

As mentioned above, a wide variety of suitable algorithms, businessrules, and/or processing techniques may be implemented in order todetermine an overdraft limit for a customer. FIG. 5 illustrates a flowdiagram of an example method 500 for calculating an overdraft limit,according to an illustrative embodiment of the invention. The method 500is one example of the operations that may be performed at block 440illustrated in FIG. 4. As such, the method 500 may be performed by asuitable financial service provider system and/or associatedoptimization computers, such as the financial service provider system105 and/or optimization computers 160 illustrated in FIG. 1. The method500 may begin at block 505.

At block 505, a determination may be made as to whether sufficientindividual customer history is available for determining an overdraftlimit that is tailored to or that is specific to an identified customer.For example, a determination may be made as to whether an availablehistory of customer account data satisfies a predetermined timethreshold. A wide variety of time thresholds may be utilized, such as athreshold of six (6) or more months, or some other suitable threshold of“X” months.

If it is determined at block 505 that a sufficient individual customerhistory is not available, then operations may continue at block 510. Atblock 510, an overdraft limit for the customer may be set to a defaultor opening overdraft limit. As desired, a default overdraft limit may bedetermined based upon preferences and/or criteria associated with afinancial institution. In other embodiments, a default overdraft limitmay be established by the financial service provider. Additionally, incertain embodiments, the same opening overdraft limit may be utilizedfor all customers failing to have a sufficient history available. Inother embodiments, an opening overdraft limit may be determined basedupon one or more criteria associated with the customer, such as aninitial deposit amount for a customer account or a current balance of anaccount. One example of establishing an opening overdraft limit basedupon an initial deposit amount is set forth in Table 1 below.

TABLE 1 Example Opening Overdraft Limits Initial Deposit Amount OpeningOverdraft Limit  $0-$100 $0 $100-$250 $25 $250-$500 $100  $500-$1000$200 $1000-$2000 $400 $2000-$5000 $500 greater than $5000 $1000

Other opening overdraft limits may be utilized as desired, and thelimits set forth in Table 1 are provided by way of example only.Following the establishment of an opening overdraft limit, the overdraftlimit may be revisited at a later point in time. For example, oncesufficient aggregate customer history has been obtained, the openingoverdraft limit may be reviewed and modified in light of the customerhistory.

If, however, it is determined at block 505 that a sufficient individualcustomer history is available, then operations may continue at block515. At block 515, a base overdraft limit for the customer may bedetermined or calculated. A wide variety of suitable methods and/ortechniques may be utilized as desired to determine a base overdraftlimit. In certain embodiments, the customer history data may beevaluated in order to determine a segment for the customer. The baseoverdraft limit may then be determined based upon the customer segment.For example, utilizing the four example customer segments illustrated inFIG. 3, a base overdraft limit may be determined as set forth in Table 2below.

TABLE 2 Example Base Overdraft Limits Customer Segment Base OverdraftLimit “1” $1250 “2” $1000 “3” $250 “4” $200

Other base overdraft limits may be utilized as desired, and the baseoverdraft limits set forth in Table 2 are provided by way of exampleonly. Additionally, in certain embodiments, one or more factors otherthan a customer segment may be utilized to determine a base overdraftlimit for a customer. For example, a business rule that considers acustomer segment, an attrition risk, and/or a customer tolerance may beutilized to determine a base overdraft limit for the customer. In thisregard, base overdraft limits may be determined in accordance with awide variety of financial institution and/or service providerpreferences.

In certain embodiments of the invention, a base overdraft limit may beadjusted by a variable amount. As desired, the variable amount may bespecific to the customer. At block 520, an acceptable variation in anoverdraft limit may be determined. A wide variety of suitable methods,formulas, algorithms, and/or techniques may be utilized as desired todetermine a variable amount for an overdraft limit. In certainembodiments, a variable amount may be determined based at least in partupon an NSF capacity ratio associated with the customer, such as ahighest NSF capacity ratio over a desired historical time period (e.g.,the past six months, the past year, etc.). One example formula forcalculating a variable amount is set forth in equation two (2) below:

$\begin{matrix}{{{VAR}_{—}{AMOUNT}} = {{PRED}_{—}{{AMOUNT} \cdot \left( \frac{{NSF}_{—}{FEES}}{{AVERAGE}_{—}{MONTHLY}_{—}{DEPOSITS}} \right)}}} & (2)\end{matrix}$

With reference to equation (2), the variable amount may be determined bydividing the total amount of NSF fees incurred over a desired historicaltime period (e.g., the past month, the past two months, the past sixmonths, etc.) by an average of the monthly deposits associated with thecustomer. The result of the ratio or division may then be multiplied bya suitable predetermined amount in order to determine the variableamount. In certain embodiments, the predetermined amount may be theaverage monthly deposit amount, although other suitable amounts may beutilized. Although equation (2) sets forth one example formula fordetermining a variable overdraft amount, other formulas and/or methodsmay be utilized as desired to determine a variable amount.

At block 525, a risk profile for the customer may be determined. A widevariety of factors may be taken into account when determining a riskprofile for the customer, such as the customer segment, an attritionrisk, a customer tolerance, a customer value, and/or a determination ofwhether NSF fees are likely to be recovered. A wide variety of differentrisk profiles may be utilized as desired in various embodiments. Forexample, a determination may be made as to whether the customer is a“low” risk, “medium” risk, or “high” risk customer. In certainembodiments, a customer's risk profile is derived at least in part froman attrition risk associated with the customer. Additionally, in certainembodiments, the determined risk profile may be utilized at block 530 todetermine whether the variable amount will be subtracted from the baseoverdraft amount, added to the base overdraft amount, or disregarded.For example, if previous overdraft fees have been incurred, and theoverdraft fees resulted in curing NSF conditions, then a customer may bea relatively low risk customer, and the base overdraft limit amount maybe increased to accommodate the customer.

If it is determined at block 530 that the customer is a “high” riskcustomer, then operations may continue at block 535. At block 535, thedetermined variable amount for the overdraft limit may be subtractedfrom the base overdraft limit for the customer. For example, utilizingan example customer that is determined to be situated in the secondcustomer segment illustrated in FIG. 3, a base overdraft limit may bedetermined to be $1000. If the customer has typical or average depositsof approximately $2000 per month, and the customer has incurred three$35 NSF fees over that past month (or the past two months), then thetotal amount of NSF fees may be calculated as $105. The variableoverdraft amount may then be calculated utilizing equation (2) as $105.This variable overdraft amount may be subtracted from the base overdraftlimit, resulting in a modified overdraft limit of $895 for the customer.

If it is determined at block 530 that the customer is a “medium” riskcustomer, then operations may continue at block 540. At block 540, thedetermined variable amount for the overdraft limit may be disregarded.Accordingly, the base overdraft limit for the customer may beestablished as the overdraft limit for the customer. If it is determinedat block 530 that the customer is a “low” risk customer, then operationsmay continue at block 545. At block 545, the determined variable amountfor the overdraft limit may be added to the base overdraft limit for thecustomer. For example, utilizing an example customer that is determinedto be situated in the second customer segment illustrated in FIG. 3, abase overdraft limit may be determined to be $1000. If the customer hastypical or average deposits of approximately $2000 per month and thecustomer has incurred one $35 NSF fee over that past month (or the pasttwo months), then the total amount of NSF fees may be calculated as $35.The variable overdraft amount may then be calculated utilizing equation(2) as $35. This variable overdraft amount may be added to the baseoverdraft limit, resulting in a modified overdraft limit of $1035 forthe customer.

As a result of the operations illustrated and described in conjunctionwith FIG. 5, an individual overdraft limit may be established for acustomer. As desired, the individual overdraft limit may take a widevariety of factors into consideration, such as a customer's value to afinancial institution, an attrition risk for the customer, and/or acustomer tolerance for absorbing NSF fees. Additionally, in certainembodiments, a base overdraft limit may be adjusted based upon acustomer's history of incurring and/or paying NSF fees.

The method 500 may end following either block 535, block 540, or block545.

The operations described and shown with reference to the above methodsmay be carried out or performed in any suitable order as desired invarious embodiments of the invention. Additionally, in certainembodiments, at least a portion of the operations may be carried out inparallel. Furthermore, in certain embodiments, less than or more thanthe operations described herein may be performed.

In addition to determining overdraft limits for customers, NSFoptimizations may be utilized for a wide variety of other purposes. Forexample, NSF optimizations may be utilized to determine account typesand/or associated fees that will be provided for certain customers. Forexample, a financial institution may offer fee-based checking as opposedto free checking. The financial institution may do so in order toincrease non-interest income. In certain embodiments, a pricingstructure may be utilized by the financial institution, and differentfees and/or account types will be offered to different customers. Asdesired, a wide variety of customer factors or attributes, such as thosedescribed above in conjunction with NSF optimizations, may be taken intoaccount to determine product offerings and/or pricing for variouscustomers. Additionally, for financial institutions that are switchingor migrating existing free checking customers to fee-based checkingaccounts, these customer factors may be utilized to identify appropriatecandidates for migration. In this regard, financial institutions mayobtain additional non-interest income from certain customers while stillretaining fee sensitive customers, such as high value fee sensitivecustomers.

As one simplified example of determining product offerings, a financialinstitution may offer four types of checking accounts. Example accounttypes may include a flat fee checking account, an extended flat feechecking account, a regular checking account, and a free checkingaccount. The flat fee checking option may typically be utilized foraccounts with relatively low balances and relatively moderate accountactivity (e.g., 10-15 checks per month). The extended flat fee checkingoption may have a higher fee than the flat fee checking option, and theextended flat fee option may be utilized for accounts with relativelylow balances and higher account activity (e.g., more than 15 checks permonth). The regular checking account option may be utilized for accountsin which unlimited checking is allowed, and the regular checking accountoption may be associated with an established fee schedule. For example,a base monthly fee and/or a fee for each check or other transaction(e.g., electronic transaction, ATM withdrawal, etc.) may be charged. Asdesired, the fees may be reduced or eliminated in the event that aminimum balance (e.g., a minimum daily balance, etc.) is maintained orin the event that other types of transactions (e.g., automatic deposits,etc.) and/or customer behavior (e.g., use of online banking and/or billpayment) occurs. The free checking option may be utilized for the mostvaluable customers and/or for customers that maintain a predeterminedaccount balance and/or that otherwise satisfy a set of conditions (e.g.,total asset on deposit conditions, loan or credit account conditions,transaction type conditions, customer behavior conditions, etc.). Theproduct offerings described above are provided by way of example only,and other offerings may be utilized as desired in other embodiments ofthe invention.

In certain embodiments, customers may be mapped to the various productofferings as a result of evaluating at least a portion of theinformation described above for NSF optimizations. For example,customers may be mapped to the product offerings in accordance with thedetermined customer segments. As one example utilizing the segmentsillustrated in FIG. 3, a first segment customer may be mapped to a freechecking account, a second segment customer may be mapped to a regularchecking account, a third segment customer may be mapped to a flat feechecking account, and a fourth segment customer may be mapped to anextended flat fee checking account. Additionally, in certainembodiments, similar account fees may be utilized for all of thecustomers assigned to a particular type of account. In otherembodiments, account fees may be customized or tailored on anindividualized basis or for subsets of customers. As desired, feesand/or product offerings may be periodically adjusted as additionalhistorical data becomes available for the customers.

The invention is described above with reference to block and flowdiagrams of systems, methods, apparatus, and/or computer programproducts according to example embodiments of the invention. It will beunderstood that one or more blocks of the block diagrams and flowdiagrams, and combinations of blocks in the block diagrams and flowdiagrams, respectively, can be implemented by computer-executableprogram instructions. Likewise, some blocks of the block diagrams andflow diagrams may not necessarily need to be performed in the orderpresented, or may not necessarily need to be performed at all, accordingto some embodiments of the invention.

These computer-executable program instructions may be loaded onto ageneral-purpose computer, a special-purpose computer, a processor, orother programmable data processing apparatus to produce a particularmachine, such that the instructions that execute on the computer,processor, or other programmable data processing apparatus create meansfor implementing one or more functions specified in the flow diagramblock or blocks. A special-purpose computer may be a general-purposecomputer that is programmed to perform one or more of the stepsdiscussed herein. These computer program instructions may also be storedin a computer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meansthat implement one or more functions specified in the flow diagram blockor blocks. As an example, embodiments of the invention may provide for acomputer program product, comprising a computer-readable medium havingone or more computer-readable programs comprising code or programinstructions embodied therein, wherein said one or morecomputer-readable programs, upon execution, implement one or morefunctions specified in the flow diagram block or blocks. The computerprogram instructions may also be loaded onto a computer or otherprogrammable data processing apparatus to cause a series of operationalelements or steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions that execute on the computer or other programmableapparatus provide elements or steps for implementing the functionsspecified in the flow diagram block or blocks.

Accordingly, blocks of the block diagrams and flow diagrams supportcombinations of means for performing the specified functions,combinations of elements or steps for performing the specifiedfunctions, and program instruction means for performing the specifiedfunctions. It will also be understood that each block of the blockdiagrams and flow diagrams, and combinations of blocks in the blockdiagrams and flow diagrams, can be implemented by special-purpose,hardware-based computer systems that perform the specified functions,elements or steps, or combinations of special-purpose hardware andcomputer instructions.

Many modifications and other embodiments of the invention will come tomind to one skilled in the art to which this invention pertains andhaving the benefit of the teachings presented in the foregoingdescriptions and the associated drawings. Therefore, it is to beunderstood that the invention is not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

What is claimed is:
 1. A system, comprising: at least one memory storingcomputer-executable instructions; and at least one processor configuredto access the at least one memory and to execute the computer-executableinstructions to: identify a customer of a financial institution, whereinthe customer is associated with a financial account at the financialinstitution; identify financial account data corresponding to one ormore financial accounts at the financial institution that are associatedwith the customer, wherein the one or more financial accounts comprisethe financial account; analyze the financial account data to determine acustomer tolerance metric for the customer, wherein the customertolerance metric is indicative of a tolerance associated with thecustomer for absorbing an actual or potential non-sufficient funds (NSF)fee assessed to the financial account; identify one or more businessrules for determining a recommended overdraft limit, wherein the one ormore business rules comprise at least one of: i) a customizable businessrule configured to be customized based at least in part on the customertolerance metric or ii) a default business rule; and execute the one ormore business rules to determine the recommended overdraft limit forassociation with the financial account.
 2. The system of claim 1,wherein the customer tolerance metric is indicative of a ratio of one ormore NSF fees assessed to at least one financial account of the one ormore financial accounts to one or more deposits to the at least onefinancial account.
 3. The system of claim 1, further comprising: atleast one network interface, wherein the at least one processor isfurther configured to execute the computer-executable instructions to:direct the at least network interface to transmit, to a systemassociated with the financial institution, a notification comprisinginformation indicative of the recommended overdraft limit, wherein thenotification comprises an instruction to associate the recommendedoverdraft limit with the financial account.
 4. The system of claim 1,further comprising: at least one network interface, wherein the at leastone processor is further configured to execute the computer-executableinstructions to: receive, via the at least one network interface, arequest for the recommended overdraft limit, wherein the customer isidentified based at least in part on customer identifying informationincluded in the request.
 5. The system of claim 1, wherein the at leastone processor is further configured to execute the computer-executableinstructions to: identify, based at least in part on an analysis of atleast a portion of the financial account data, a customer segmentassociated with the customer, wherein the recommended overdraft limit isfurther determined based at least in part on the customer segment. 6.The system of claim 5, wherein the at least one processor is configuredto identify the customer segment by executing the computer-executableinstructions to: analyze the at least a portion of the financial accountdata to determine a first value indicative of an estimate of interestincome associated with the one or more financial accounts and a secondvalue indicative of an estimate of non-interest income associated withthe one or more financial accounts; compare the first value and thesecond value to respective threshold values; and associate the customerwith the customer segment based at least in part on a result ofcomparing the first value and the second value to the respectivethreshold values.
 7. The system of claim 1, wherein the at least oneprocessor is further configured to execute the computer-executableinstructions to: determine, based at least in part on an analysis of atleast a portion of the financial account data, an attrition riskassociated with the customer, wherein the recommended overdraft limit isfurther determined based at least in part on the attrition risk.
 8. Thesystem of claim 7, wherein the at least one processor is configured todetermine the attrition risk by executing the computer-executableinstructions to: determine a respective value for the customer for eachof one or more customer attributes based at least in part on theanalysis of the at least a portion of the financial account data;provide each respective value as input to one or more predictive models;receive output from the one or more predictive models; and determine anattrition risk value indicative of the attrition risk associated withthe customer based at least in part on the output received from the oneor more predictive models.
 9. The system of claim 1, wherein the one ormore business rules comprise the customizable business rule, and whereinthe at least one processor is further configured to execute thecomputer-executable instructions to: customize the customizable businessrule to generate a customized business rule based at least in part on atleast one of: i) the customer tolerance metric, ii) a customer segmentassociated with the customer, iii) an attrition risk value associatedwith the customer, or iv) one or more data attributes associated withthe customer.
 10. The system of claim 1, wherein at least one businessrule of the one or more business rules specifies one or more customertolerance metric thresholds, and wherein the at least one processor isconfigured to execute the at least one business rule by executing thecomputer-executable instructions to: compare the customer tolerancemetric to at least one of the one or more customer tolerance metricthresholds to at least partially determine the recommended overdraftlimit.
 11. The system of claim 1, wherein the at least one processor isconfigured to execute the one or more business rules by executing thecomputer-executable instructions to: determine that the financialaccount data comprises historical customer account data for at least athreshold period of time; determine a base overdraft limit based atleast in part on an analysis of the historical customer account data;determine a risk profile associated with the customer based at least inpart on the customer tolerance metric; and determine the recommendedoverdraft limit based at least in part on the base overdraft limit andthe risk profile associated with the customer.
 12. The system of claim11, wherein at least one of: i) the risk profile indicates that thecustomer is a high-risk customer and the recommended overdraft limitcomprises a sum of the base overdraft limit and a variance associatedwith the base overdraft limit, ii) the risk profile indicates that thecustomer is a medium-risk customer and the recommended overdraft limitcomprises only the base overdraft limit, or iii) the risk profileindicates that the customer is a low-risk customer and the recommendedoverdraft limit comprises a difference between the base overdraft limitand the variance.
 13. A method, comprising: identifying, by acomputerized financial system comprising one or more computers, acustomer of a financial institution, wherein the customer is associatedwith a financial account at the financial institution; identifying, bythe computerized financial system, financial account data correspondingto one or more financial accounts at the financial institution that areassociated with the customer, wherein the one or more financial accountscomprise the financial account; analyzing, by the computerized financialsystem, the financial account data to determine a customer tolerancemetric for the customer, wherein the customer tolerance metric isindicative of a tolerance associated with the customer for absorbing anactual or potential non-sufficient funds (NSF) fee assessed to thefinancial account; identifying, by the computerized financial system,one or more business rules for determining a recommended overdraftlimit, wherein the one or more business rules comprise at least one of:i) a customizable business rule configured to be customized based atleast in part on the customer tolerance metric or ii) a default businessrule; and executing, by the computerized financial system, the one ormore business rules to determine the recommended overdraft limit forassociation with the financial account.
 14. The method of claim 13,wherein the customer tolerance metric is indicative of a ratio of one ormore NSF fees assessed to at least one financial account of the one ormore financial accounts to one or more deposits to the at least onefinancial account.
 15. The method of claim 13, further comprising:identifying, by the computerized financial system and based at least inpart on an analysis of at least a portion of the financial account data,a customer segment associated with the customer, wherein the recommendedoverdraft limit is further determined based at least in part on thecustomer segment.
 16. The method of claim 15, wherein identifying thecustomer segment further comprises: analyzing, by the computerizedfinancial system, the at least a portion of the financial account datato determine a first value indicative of an estimate of interest incomeassociated with the one or more financial accounts and a second valueindicative of an estimate of non-interest income associated with the oneor more financial accounts; comparing, by the computerized financialsystem, the first value and the second value to respective thresholdvalues; and associating, by the computerized financial system, thecustomer with the customer segment based at least in part on a result ofthe comparing.
 17. The method of claim 13, wherein the one or morebusiness rules comprise the customizable business rule, the methodfurther comprising: customizing, by the computerized financial system,the customizable business rule to generate a customized business rulebased at least in part on at least one of: i) the customer tolerancemetric, ii) a customer segment associated with the customer, iii) anattrition risk value associated with the customer, or iv) one or moredata attributes associated with the customer.
 18. The method of claim13, wherein executing the one or more business rules comprises:determining, by the computerized financial system, that the financialaccount data comprises historical customer account data for at least athreshold period of time; determining, by the computerized financialsystem, a base overdraft limit based at least in part on an analysis ofthe historical customer account data; determining, by the computerizedfinancial system, a risk profile associated with the customer based atleast in part on the customer tolerance metric; and determining, by thecomputerized financial system, the recommended overdraft limit based atleast in part on the base overdraft limit and the risk profileassociated with the customer.
 19. The method of claim 18, wherein atleast one of: i) the risk profile indicates that the customer is ahigh-risk customer and the recommended overdraft limit comprises a sumof the base overdraft limit and a variance associated with the baseoverdraft limit, ii) the risk profile indicates that the customer is amedium-risk customer and the recommended overdraft limit comprises onlythe base overdraft limit, or iii) the risk profile indicates that thecustomer is a low-risk customer and the recommended overdraft limitcomprises a difference between the base overdraft limit and thevariance.
 20. The method of claim 13, wherein at least one business ruleof the one or more business rules specifies one or more customertolerance metric thresholds, the method further comprising: comparing,by the computerized financial system, the customer tolerance metric toat least one of the one or more customer tolerance metric thresholds toat least partially determine the recommended overdraft limit.